Generalizing Def and Pos to Type Analysis

This paper is concerned with the type analysis of logic programs where, by type, we mean a property closed under instantiation. We define a chain of abstractions from Herbrand constraints to logical formulas via the set of their solutions. Every step of the chain is an instance of abstract interpretation. The use of logical formulas for type analysis is a generalization of the traditional Boolean domains and for groundness analysis. In this context, implication is the logical counterpart of the use of linear refinement. While logical formulas can sometime be used for an actual implementation of our domains, in the general case they are infinite objects. Therefore, we apply a final abstraction from possibly infinite logical formulas to (finite) logic programs. Thus, logic programs are themselves used for the type analysis of logic programs. The advantage of our technique with respect to the many frameworks for type analysis present in the literature is that we have developed our domains by using the formal techniques of abstract interpretation and linear refinement. Therefore, their construction is guided by the underlying theory, from which their properties are derived. Keywords: Abstract interpretation, domain theory, linear refinement, type theory, type analysis, logic programming. 1 Introduction This paper is concerned with the type analysis of logic programs where, by type, we mean a downward closed property, that is, a property closed under instantiation. For instance, the set of integers and the set of lists are types, since once a variable is bound to an integer or a list it will maintain this property throughout the computation. Similarly, the set of all difference lists is a type. On the other hand, the set of all free variables is not a type since freeness can be lost by computation. Type analysis is the upward approximation of the success set of a program through types. Type analysis of logic programs is important for optimization of unification as well as for verification. For instance, the programmer can use type analysis to check that the arguments of all procedure calls that can arise at run-time actually belong to some types. Note that we do not consider how to check whether they are input or output parameters. Similarly, if a compiler knows that a given variable is bound to an integer in a given program point then it can generate a specialized code for the unification of that variable. A well-known and useful type, which distinguishes whether a term contains variables or not, is groundness [2, 10, 11]. The usual domains for groundness analysis, and , feature some desirable properties: simplicity, effectivity, usefulness. Moreover, it has been J. Logic Computat., Vol. 12 No. 3, pp. 497–542 2002 c Oxford University Press 498 Generalizing Def and Pos to Type Analysis shown [34, 44] that is condensing, i.e. it propagates the property of groundness in the best possible way. Finally, it can be used for abstract compilation [8, 23]. All these good properties of the domain should have encouraged a generalization of to a general type domain. Instead, type domains have been developed, up to now, in a way which is almost always totally independent from the domain for groundness analysis. A generalization of groundness to generic types is given in [8], but it is assumed, without any proof of correctness, that the usual properties that hold for and in the case of groundness still hold for all the type domains. In [42] the domain is combined with type information. However, the resulting abstract domain is not induced by any underlying theory, and it is not possible to speak of any form of optimality for it. We do not know of any approach where the abstract domains for inferring a generic type system are developed in an automatic way, and choices about the representation and the algorithms are implied by the same theory of abstract interpretation. This is exactly the distinguishing feature of our construction. Note that we discuss related work in more detail in Subsection 1.1. In this paper we generalize the construction of groundness to a generic type domain. In Section 3 we show that the domain of existential Herbrand constraints is isomorphic to the domain of their solutions. Therefore, the powersets and , the domains of the collecting semantics, can express any properties of the existential Herbrand constraints. Since we are interested in types, we abstract these powersets into a domain of downward (instantiation) closed sets of substitutions. The optimal counterparts over of the operations over existential Herbrand constraints are explicitly defined. In Section 4 we consider a type-dependent abstraction from to a set of transfinite formulas. If, in this abstraction, we use groundness and the set of positive transfinite formulas, we obtain the domain for groundness analysis. We obtain by considering definite transfinite formulas. However, our construction is much more general, and can be applied to every type and set of transfinite formulas. Moreover, if a very weak condition holds for the type and the set of formulas, then the good properties of and in the case of groundness can be generalized to the new abstract domain of transfinite formulas. Namely, a Galois insertion exists between and that domain so that it does not contain useless elements. Moreover, the traditional abstract operations over transfinite formulas (conjunction and Schröder elimination) are the optimal counterparts of the operations over . Therefore, the use of transfinite formulas as a representation of type domains does not introduce any loss of precision for the computation of the abstract operators. We show that some sets of transfinite formulas are optimal, in the sense of being closed w.r.t. a linear refinement operation. The generalization of the set of transfinite formulas to generic types can be used for actual type analysis only in the very special case when its formulas are finite, like in the case of groundness or non-freeness. In Section 5 we show that, when this is not the case, the transfinite formulas of can be abstracted into a finite domain of logic programs. We provide correct and sometimes optimal counterparts over logic programs of the operations over transfinite formulas. Therefore, we justify, by a formal construction through abstract interpretation and linear refinement, the use of logic programs for the analysis of logic programs themselves [16]. In Section 6 we show some examples of type analysis of logic programs through our domain . The picture below synthesizes the various domains considered in this paper, and their relationships as abstraction (represented by horizontal arrows) or lifting to the powerset (represented by vertical arrows). Generalizing Def and Pos to Type Analysis 499 collecting non-collecting typedependent type-independent abstractions abstractions Partial and preliminary versions of this paper appeared in [25] and [32]. 1.1 Related work It is common to divide approaches to types (in logic programming) into those that require the types to be declared by the user and those that expect them to be inferred by the system [43]. Type systems designed for the first approach are often said to be prescriptive whereas those intended for the second are called descriptive [41]. However, this division is rather artificial and instead, we prefer to see a continuous spectrum between completely type specified programs and untyped ones. At the top end of the spectrum, when the types are completely specified, the type checking is then a matter of exploiting any redundant information to check that the program and type declarations are consistent. When the rules for the type system together with a partial type specification in the program are sufficient to uniquely specify the program types, then type reconstruction is used to determine any missing type information [31, 36]. The majority of typed logic programming languages such as Gödel [24] and Mercury [46] use a combination of type checking and type reconstruction, the latter often being used to determine the types of the variables. If, however, insufficient or no type information is provided, then it is the job of a type inference tool to type the program so that the program is well-typed and any results that may be computed are also well-typed. In all cases, it is assumed that no type errors can occur at run-time. Although, in this paper, we are concerned with type inference and hence towards the lower end of this spectrum, we do assume that the types themselves are already defined. Moreover, as we are interested in generalizing the groundness analysis techniques to types, we require that these types enjoy the same downward closed property that the groundness domains possess. Such a condition on types is common in work on type analysis [8, 28]. In particular, this means that, if the analyser infers a typing of the program so that each clause is well-typed, then every instance of the clause will be well-typed. Regarding the actual approach to type analysis, some techniques are similar to those developed for (higher order) functional languages (see, for example, [3, 30, 40, 41, 49]) while others are inspired by program verification methods [1]. Others use type graphs [28, 47]. We use here the abstract interpretation framework of [13] which is the basis for the type analysis techniques of many proposals [4, 8, 9, 28, 29, 33, 45, 48, 49]. The first step in designing a type inference system based on abstract interpretation is to decide on the abstract domain. For type inference, it is important that the abstract domain can express generic dependencies between the types. As shown in [7], if the types are ground (i.e. monomorphic), one cannot handle generic type dependencies. This is illustrated in [4] which describes an inference system which uses only ground types. As a result their abstract domains are usually infinite and hence impractical without widening. Polymorphic types using type variables (often called parameters) in the type language were first proposed for 500 Generalizing Def and Pos to Type Analysis logic programming in [37] and then formalized in [22, 26],1 although these were intended for use with type checking rather than type inference. These types have since been adapted in a number of ways for use with type inference systems, such as in [29, 33, 48]. The use of parametric polymorphism to express type dependencies between a procedure’s arguments is a standard solution, used for instance in [4, 9, 28, 49]. The same solution is used in the framework of regular approximation of the success set in [18, 49]. However, the use of type variables does not allow one to express all type dependencies between argument positions. Only in [4, 8, 42] are there examples of domains which explicitly allow one to express type dependencies between polymorphic types. There are two ways in which groundness analysis may be generalized to types. First, as is the case in [45], the property of groundness itself can be generalized. There, it is assumed that the language is already completely typed and the authors provide a means of constructing mode domains for representing different degrees of instantiation of well-typed expressions occurring in the execution of a program. Thus the typed modes generalize the property of whether or not a variable is bound to a ground term and are intended for use with abstract compilation. Secondly, as described in [8], polymorphic types may be obtained through a generalization of a domain like , the domain for propagating groundness. There, it is assumed that the usual properties that hold for in the case of groundness still hold for its generalization to types. For instance, logical conjunction between formulas is used as conjunction operator and Schröder elimination as cylindrification operator. However, it is not obvious at all that these operators, which are optimal in the case of groundness analysis, as shown in [11], are even correct in the general case of type analysis and no proof is given. Although in [9] a domain with properties similar to those of is defined, it is not a generalization of . For instance, it is not made of logical formulas. Finally, in [42], is combined with type information. However, their construction is not the result of any automatic, methodological construction which starts from the properties of interest and leads to the abstract domain. 2 Preliminaries The powerset of a set is . We denote by the set of all finite subsets of . If is partially ordered w.r.t. and , we denote by the downward closure of and by the set of all the downward closed sets of . A sequence is an ordered collection of elements. The set of sequences over is denoted by . If  is a sequence we will silently assume that , where is the length of the sequence. 2.1 S-semantics We define the semantics of logic programs by the use of the s-semantics approach [6]. The s-semantics is a bottom-up, fixpoint definition of the set of computed answers of a program, though it can be rephrased for call pattern or resultant analysis [17]. We assume there is an infinite set of program variables . For our purposes, we give a very abstract definition of constraint system over as a data structure together with three operations. 1Although, as indicated in [5] there is an error in the development of the type system in [26], this does not affect the results for pure parametric polymorphism when subtypes are ignored. Generalizing Def and Pos to Type Analysis 501 DEFINITION 2.1 A constraint system over a set of variables is a family of sets together with three operations: for we have a (partial) infix conjunction operation , a (partial) renaming operation and a (total) cylindrification operation . We write for and  for . In the following, when speaking of renaming, we will silently assume that and are two disjoint sequences in without repetitions. Note that the definition above is very abstract since it does not make any assumption about the behaviour of conjunction, renaming and cylindrification except for their signatures. EXAMPLE 2.2 For every , let . This means that the constraints over the variables are all the subsets of . We define the operations , and , where  means substitution of the variables  with the variables (see Subsection 2.2). These operations respect the signatures of Definition 2.1. In Subsection 2.3 we will see a more complex and useful constraint system. It turns out that the constraints of Example 2.2 track the set of variables used by the constraints of Subsection 2.3. Moreover, in the following sections we will present every abstract domain as a constraint system. Given a constraint system, we can define the set of goals and programs. DEFINITION 2.3 Let be a constraint system and a finite set of predicate symbols with associated arity. We denote by the set of distinct variables where is the maximum arity of the predicates in . Assume . By we refer to the set of goals over , as defined by the grammar where , with and are distinct variables not in . By we refer to the set of programs over , i.e. to the set of sets of clauses, at most one for every predicate symbol, where the clause for has the form where and are distinct variables not in . We write for if has arity . Note that this abstract syntax will be used only for the programs we want to analyse. When we consider a Prolog program before its transformation into the syntax of Definition 2.3, instead, we will use its standard syntax [27]. The meaning of a program is an interpretation, i.e. a map from predicate symbols to sets of constraints. DEFINITION 2.4 An interpretation over the constraint system is a function . The set of interpretations over is denoted by . The set is a complete lattice w.r.t. the 502 Generalizing Def and Pos to Type Analysis ordering defined as if and only if for every . The least upper bound and greatest lower bound operations are and defined as respectively, with and . The bottom interpretation is such that for every . If then is the meaning that gives to . Every constraint in refers to the arguments of through the variables in . For instance, the first argument is referred to as , the second as and so on. This means that we can obtain the meaning of a procedure call simply by substituting by for every . Given an interpretation, we define the evaluation of a goal (query), i.e. the set of computed answers obtained by executing the goal in a context where procedure calls are denoted by the interpretation. DEFINITION 2.5 Given and , let